Packet-based timing methods are becoming essential for delivering timing over packet-switched networks, often referred to as the cloud. In particular, Precision Timing Protocol (PTP) (i.e., IEEE 1588v2) is becoming popular for delivering timing information (time/phase/frequency) from a Grand Master (GM) clock to slave clocks in end application-specific equipment. For example, wireless base stations providing mobile telephony services require precise timing, and the backhaul method of choice is Ethernet.
The Grand Master clock provides timing information over the packet-switched network to the slave clocks by exchanging packets with embedded time-stamps related to the time-of-arrival and time-of-departure of the timing packets. The slave clock utilizes this information to align its time (and frequency) with the Grand Master. The Grand Master is provided an external reference to serve as the basis for time and frequency. Most commonly, this reference is derived from the GPS System that in turn is controlled by the US Department of Defense, and its timing is controlled very precisely and linked to the US Naval Observatory.
The quality of timing transfer is greatly affected by packet delay variation (PDV). PDV is the phenomenon whereby different packets take different times to traverse the network between the communicating clocks. PDV is influenced primarily by traffic loading. The higher is the traffic load in the network; the greater is the extent of packet delay variation. Conversely, monitoring the quality of timing transfer between two points in a network provides visibility into the traffic loading in the network segment between these two points.
Prior methods for monitoring employ a slave-like clock device that communicates with the master over all or part of the same network over which the actual slave communicates with the master. The slave-like clock device has its own reference and does not actually discipline its local clock according to the timing messages between the device and the master but just retains the time-stamps and thereby estimates the PDV behavior. This behavior is then inferred as the network condition that the actual slave will experience when actually deployed.
As described above, one of the more important requirements of a digital communication network is to support real-time communications applications which, typically, require time or frequency alignment, or a combination of both. For example, time alignment is used by real-time instrumentation systems gathering data at specific time intervals or by machinery operating according to specific timing. Frequency alignment is required in time-division-multiplexed (TDM) systems and in multi-media streaming systems, which require fixed, reproducible, video or audio sample rates across multiple clients. One of the most popular uses of packet-based timing in modern telecommunications networks is to support mobile telephony deployments.
FIG. 1 (Prior Art) is a conceptual diagram that illustrates a mobile telephony deployment in terms of the timing and synchronization aspect of the packet network 100. At each cellular base station, also referred to as a Node-B and in the case of packet-network interconnect as an eNode-B, there is a slave clock 120 (also 121) that must be synchronized with all the other clocks in base stations that collectively comprise the cellular access network. The clocks are synchronized by aligning each one to a grand master clock 105. The grand master clock 105 typically develops its timing reference from a Global Navigation Satellite System (GNSS), such as GPS (Global Positioning Systems), using a GPS receiver (with GPS antenna) 140. In the example shown, the clocks and their interactions, as well as the terminology used, are governed by the PTP (Precision Timing Protocol), also referred to as IEEE 1588 which is the designation of the standard. In the example considered, the GNSS of choice is the GPS system. The timing information is carried using packets, and there is a packet flow 150 between the grandmaster clock 105 and each of the slave clocks 120/121 that are in the alignment set. In normal operation, because the slave clocks 120/121 are all synchronized directly or indirectly to a common reference, the GNSS, they are all mutually aligned in time and frequency. For specificity and simplicity of explanation, it is assumed that the network does not provide on-path support in the form of transparent clocks or boundary clocks; however, the extension of the concepts described herein are easily extended to the case where the network provides on-path support or partial on-path support. With this assumption, it suffices to refer to the grand master 105 in FIG. 1 (Prior Art) as simply “master.”
The manner in which the slave clocks 120/121 align themselves with the master 105 is explained using FIG. 2 (Prior Art). Packet exchanges between master and slave provide measurements of the transit delay between the two. The particular protocol employed determines the method whereby the measurements (“time-stamps”) are communicated between the two entities. This protocol can be, for example, PTP or NTP (Network Time Protocol). Both are supported by packet networks in a transparent fashion. For specificity, the examples described assume PTP.
Referring to FIG. 2 (Prior Art), the sequence of events and important items of information associated with an exchange of packets between master 210 and slave 220 are:                Event A 230: Packet (in PTP this is the Sync_message) is transmitted by master 210 and the time-of-departure 251 is t1.        Event B 232: The packet (Sync_message) arrives at slave 220 that measures the time-of-arrival as τ2; assuming that the slave time offset from master (ofm) is ε, the actual time-of-arrival 252 is t2=τ2+ε.        Event C 234: Packet (e.g., the PTP message referred to as Delay_request) is transmitted by slave 220 that notes the time-of-departure is τ3; assuming that the slave time offset from master is ε, the actual time-of-departure 253 is t3=τ3+ε.        Event D 236: The packet (Delay_request) arrives at master 210 that measures time-of-arrival 254 as t4.        Event E 237: Packet (the Delay_response message) is sent from the master 210 towards the slave 220, and the content of the packet contains the time-of-arrival t4 254 (of the Delay_request at the master).        Event F 238: The packet (Delay_response) arrives at the slave 220. Now the slave clock has all four of the relevant time-of-arrival and time-of-departure values associated with this exchange of packets.        
Such a two-way exchange of packets can provide information suitable for allowing the slave 220 to align in time with the master 210 (assuming that both sides have knowledge of the time stamps). If the exchange of information is only one-way from master 210 to slave 220 (referred to as the forward direction), the slave 220 can still align its clock (frequency) with the master (syntonization) because the packet contains the time-of-departure 251 from the master (t1) and because the slave 220 measures the time-of-arrival (τ2). One-way methods, where the time-stamped packets flow from slave 220 to master 210, can be employed provided a mechanism is available for the slave 220 to obtain the results of the master measuring time-of-arrival at the master (t4).
There are four measured values that can be communicated between the master and slave, namely, (t1, τ2, τ3, t4). It is noted that such a two-way exchange involves one packet (message) in each direction, and they do not necessarily have to be consecutive as long as the time-stamp information is communicated appropriately. In some instances, the rate at which packets are transmitted in the two directions can be different. Denoting by ΔMS 240 and ΔSM 244 the transit delays between the master and slave and vice versa, the following equations can be established:t4=τ3+ε+ΔSM (from an S-to-M packet)t1=τ2+ε−ΔMS (from a M-to-S packet)  (Eq. 1)
In an actual time-transfer situation, there are two equations with three unknowns. As such, it is common to assume reciprocity of transit delay between the two devices, thereby reducing the number of unknowns to two and therefore computing e, the slave time offset from master from (Eq. 2).
                    ɛ        =                                                            (                                                      t                    4                                    +                                      t                    1                                                  )                            -                              (                                                      τ                    3                                    +                                      τ                    2                                                  )                                      2                    =                                                    (                                                      t                    4                                    -                                      τ                    3                                                  )                            -                              (                                                      τ                    2                                    -                                      t                    1                                                  )                                      2                                              (                  Eq          .                                          ⁢          2                )            
Because of the fundamental statistical behavior of packet networks, the transit delays are not fixed and can vary from packet to packet. To counter this packet delay variation, as well as to account for any drift in the slave clock oscillator, the estimates of clock offset are made routinely, and it is well known that the mitigation of the deleterious effects of packet delay variation and oscillator drift is improved by using more frequent exchanges of timing packets. Ordinary slave clocks 120 (also 121) develop their estimate of time offset from master based on (Eq. 2).